Stream: Internet Architecture Board (IAB) 


RFC: 8722 

Obsoletes: 6220 

Category: Informational 

Published: February 2020 

ISSN: 2070-1721 

Authors: D. McPherson, Ed. O. Kolkman, Ed. J. Klensin, Ed. G. Huston, Ed. 
Verisign, Inc. ISOC APNIC 


RFC 8722 
Defining the Role and Function of IETF Protocol 
Parameter Registry Operators 


Abstract 


Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values 
that are passed in messages or packets. To ensure consistent interpretation of these values 
between independent implementations, there is a need to ensure that the values and associated 
semantic intent are uniquely defined. The IETF uses registry functions to record assigned 
protocol parameter values and their associated semantic intentions. For each IETF protocol 
parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry 
Operator to a nominated entity. This document provides a description of, and the requirements 
for, these delegated functions. This document obsoletes RFC 6220 to replace all references to the 
IETF Administrative Support Activity (IASA) and related structures with those defined by the 
IASA 2.0 Model. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for informational 
purposes. 


This document is a product of the Internet Architecture Board (IAB) and represents information 
that the IAB has deemed valuable to provide for permanent record. It represents the consensus 
of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not 
candidates for any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc8722. 


Copyright Notice 


Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights 
reserved. 
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1. Overview 


Many IETF protocols make use of commonly defined values that are passed within messages or 
packets. To ensure consistent interpretation of these values between independent 
implementations, there is a need to ensure that the values and associated semantic intent are 
uniquely defined. The IETF uses registries to record each of the possible values of a protocol 
parameter and their associated semantic intent. These registries, their registration policy, and the 
layout of their content are defined in the so-called "IANA Considerations" sections of IETF 
documents. 


The organizational separation between the IETF and its Protocol Parameter Registry Operators 
parallels ones that are fairly common among standards development organizations (SDOs) 
although less common among technology consortia and similar bodies. These functions have 
been separated into different organizations for several reasons. They include dealing with 
administrative issues, addressing concerns about maintaining an adequate distance between 
basic policy and specific allocations, and avoiding any potential conflicts of interest that might 
arise from commercial or organizational relationships. For example, most ISO and ISO/IEC JTC1 
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standards that require registration activities specify a Registration Authority (RA) or 
Maintenance Agency (MA) that, in turn, control the actual registration decisions. The databases 
of what is registered for each standard may then be maintained by a secretariat or database 
function associated with the RA or MA or, less frequently, by the secretariat of the body that 
created and maintains the standard itself. 


This structural separation of roles exists within several places in the IETF framework (e.g., the 
RFC Editor function). The Internet Architecture Board (IAB), on behalf of the IETF, has the 
responsibility to define and manage the relationship with the Protocol Parameter Registry 
Operator role. This responsibility includes the selection and management of the Protocol 
Parameter Registry Operator, as well as management of the parameter registration process and 
the guidelines for parameter allocation. 


As with other SDOs, although it may delegate authority for some specific decisions, the IETF 
asserts authority and responsibility for the management of all of its protocol parameters and 
their registries, even while it generally remains isolated from the selection of particular values 
once a registration is approved. This document describes the function of these registries as they 
apply to individual protocol parameters defined by the IETF Internet Standards Process (see RFC 
6410 [BCP9]) to allow for an orderly implementation by the IETF Administration Limited Liability 
Company (IETF LLC), and others as needed, under guidance from the IAB. This document 
obsoletes RFC 6220 to replace all references to the IASA and related structures with those defined 
by the IASA 2.0 Model [RFC8711]. 


Below we provide a description of the requirements for these delegated functions, which the 
IETF traditionally refers to as the Internet Assigned Numbers Authority (IANA) function. 


2. Roles and Responsibilities Concerning IETF Protocol 
Parameter Registries 


The IETF's longstanding practice is to outsource the management and implementation of some 
important functions (e.g., [RFC8728]). The protocol parameter registry function falls into this 
category of outsourced functions, and what follows here is the description of the roles and 
responsibilities with respect to the registration of IETF protocol parameters. 


Specifically, this document describes the operation and role of a delegated IETF Protocol 
Parameter Registry Operator, to be selected and administered by the IETF Administrative 
Support Activity (IASA) [RFC8711]. While there is generally a single Protocol Parameter Registry 
Operator, additional Operators may be selected to implement specific registries, and that has 
been done occasionally. Having a single Protocol Parameter Registry Operator facilitates 
coordination among registries, even those that are not obviously related, and also makes it easier 
to have consistency of formats and registry structure, which aids users of the registries and 
assists with quality control. 


Many protocols make use of identifiers consisting of constants and other well-known values. 
Even after a protocol has been defined and deployment has begun, new values may need to be 
assigned (e.g., for a new option type in DHCP, or a new encryption or authentication algorithm 
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for IPsec). To ensure that such quantities have consistent values and interpretations in different 
implementations, their assignment must be administered by a central authority. For IETF 
protocols, that role is provided by a delegated Protocol Parameter Registry Operator. For any 
particular protocol parameter there is a single delegated Registry Operator. 


2.1. Protocol Parameter Registry Operator Role 


The IETF Protocol Parameter Registry function is undertaken under the auspices of the Internet 
Architecture Board. 


The roles of the Protocol Parameter Registry Operator (Registry Operator) are as follows: 
e Review and Advise 


o A Registry Operator may be requested to review Internet-Drafts that are being considered 
by the Internet Engineering Steering Group (IESG), with the objective of offering advice to 
the IESG regarding the contents of the "IANA Considerations" section, whether such a 
section, when required, is clear in terms of direction to the Registry Operator, and whether 
the section is consistent with the current published Registry Operator guidelines. 


e Registry 


o To operate a registry of protocol parameter assignments. 


° The delegated Registry Operator registers values for Internet protocol parameters only as 
directed by the criteria and procedures specified in RFCs, including Standards Track 
documents [BCP9], Best Current Practice documents, and other RFCs that require protocol 
parameter assignment. 


If values for Internet protocol parameters were not specified, or in case of ambiguity, the 
Registry Operator will continue to assign and register only those protocol parameters that 
have already been delegated to the Registry Operator, following past and current practice 
for such assignments, unless otherwise directed in terms of operating practice by the IESG. 
In the case of ambiguity, the Registry Operator is expected to identify the ambiguity to the 
IAB or IESG as appropriate and either suggest better text or ask the appropriate parties for 
clarification. 


° For each protocol parameter, the associated registry includes: 


«a reference to the RFC document that describes the parameter and the associated "IANA 
Considerations" concerning the parameter, and 


« for each registration of a protocol parameter value, the source of the registration and the 
date of the registration, if the date of registration is known, and 

« any other information specified as being included in the registration data in the RFC 
document that describes the parameter. 

« If in doubt or in case of a technical dispute, the Registry Operator will seek and follow 
technical guidance exclusively from the IESG. Where appropriate, the IESG will appoint 
an expert to advise the Registry Operator. 
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o The Registry Operator will work with the IETF to develop any missing criteria and 
procedures over time, which the Registry Operator will adopt when so instructed by the 
IESG. 


o Unless special circumstances apply to subsets of the data and specific rules are established 
by IETF consensus, each protocol parameter registry operates as a public registry, and the 
contents of the registry are openly available to the public, on-line and free of charge. 


o The Registry Operator assigns protocol parameter values in accordance with the policy 
associated with the protocol parameter, such as "First Come First Served" or "Expert 
Review" [RFC8126]. 


e Mailing Lists 


° The Registry Operator maintains public mailing lists as specified in IANA Considerations 
[RFC8126]. Such lists are designated for the purpose of review of assignment proposals in 
conjunction with a designated expert review function. In addition, each Registry Operator 
should maintain a mailing list that enables the registry staff of the Registry Operator to be 
contacted by email. 


e Liaison Activity 


o The Registry Operator will nominate a liaison point of contact. The Registry Operator, 
through this liaison, may be requested to provide advice to the IESG on IETF protocol 
parameters as well as the "IANA Considerations" section of each Internet-Draft that is 
being reviewed for publication as an RFC. Where appropriate the IESG will appoint an 
expert to advise the Registry Operator. 


e Reporting 


o The Registry Operator will submit periodic reports to the IAB concerning the operational 
performance of the registry function. As an example of the requirements for such reports, 
the reader is referred to a supplement [MoU_SUPP2019] to the "Memorandum of 
Understanding Concerning the Technical Work of the Internet Assigned Numbers 
Authority" [RFC2860] that provides service level agreement (SLA) guidelines under which 
ICANN, the current protocol parameter registry, must operate. 

o At the request of the chair of the IETF or IAB, or the IETF Executive Director [RFC8711], the 
Registry Operator will undertake periodic reports to IETF Plenary meetings or elsewhere 
as directed, concerning the status of the registry function. 

o The Registry Operator will publish an annual report describing the status of the function 
and a summary of performance indicators. 


e Intellectual Property Rights and the Registry Operator 
Unless special circumstances apply (see above): 


° All assigned values are to be published and made available free of any charges. 
° The assignment values may be redistributed without modification. 
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In any case, 


° any intellectual property rights of the IETF protocol parameter assignment information, 
including the IETF protocol parameter registry and its contents, are to be held by the IETF 
Trust [RFC8711] [RFC8714]. 


2.2. IAB Role 


An Operator of an IETF protocol parameter registry undertakes the role as a delegated function 
under the authority of the IAB. 


The IAB has the responsibility to review the current description of the registry function from 
time to time and direct the Registry Operator to adopt amendments relating to its role and mode 
of operation according to the best interests of the IETF and the Internet community in general. 


The IAB has the responsibility to appoint an organization to undertake the delegated functions of 
the Registry Operator for each IETF protocol parameter. Specifically, the IAB defines the role and 
requirements for the desired functions. The IETF LLC is responsible for identifying a potential 
vendor, and once under agreement, managing the various aspects of the relationships with that 
vendor. To be clear, the IAB is in the deciding role (e.g., for appointment and termination), but 
must work in close consultation with the IETF LLC. 


The IAB has the responsibility to determine the terms and conditions of this delegated role. Such 
terms and conditions should ensure that the registry operates in a manner that is fully 
conformant to the functions described in this document. In addition, such terms and conditions 
must not restrict the rights and interests of the IETF with respect to the registry contents and 
maintenance. 


2.3. IESG Role 


The IESG is responsible for the technical direction regarding entries into IETF protocol 
parameter registries and maintaining the policies by which such technical directions are given. 
Technical direction itself is provided through the adoption of directives within the "IANA 
Considerations" section of IETF Stream RFCs or through stand-alone "IANA Considerations" RFCs. 


The IESG shall verify that Internet-Drafts that are offered for publication as IETF Stream RFCs 
[RFC8729] include "IANA Considerations" sections when needed, and that "IANA Considerations" 
sections conform to the current published guidelines. 


Since technical assessment is not generally a responsibility of the Registry Operator, as part of 
providing the technical direction the IESG is responsible for identifying the technical experts that 
are required to, where appropriate, review registration requests or resolve open technical 
questions that relate to the registration of parameters. 


At its discretion, the IESG will organize the liaison activities with the Registry Operator's liaison 
point of contact so as to facilitate clear communications and effective operation of the registry 
function. 
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2.4. Role of the IETF Trust 


The IETF Trust [RFC4371] was formed to act as the administrative custodian of all copyrights and 
other intellectual property rights relating to the IETF Standards Process, a function that had 
previously been performed by the Internet Society (ISOC) and the Corporation for National 
Research Initiatives (CNRI). 


Any intellectual property rights of IETF protocol parameter assignment information, including 
the registry and its contents, and all registry publications, are to be held by the IETF Trust on 
behalf of the IETF. 


The IETF Trust may make such regulations as appropriate for the redistribution of assignment 
values and registry publications. 


2.5. Role of the IETF Administration Limited Liability Company 


The IETF Administration Limited Liability Company (IETF LLC) [RFC8711] is responsible for 
identifying a potential vendor in a manner of its choosing, based on IAB consultation, and for 
managing the various aspects of the relationships with that vendor. 


In addition, the IETF LLC has the responsibility to ensure long-term access, stability, and 
uniqueness across all such registries. This responsibility is of particular significance in the event 
that a relation with a Protocol Parameter Registry Operator is terminated. 


3. Miscellaneous Considerations 


While this document has focused on the creation of protocols by the IETF, the requirements 
provided are generically applicable to the extended IETF community as well (e.g., Internet 
Research Task Force (IRTF)). 


The IESG is responsible for the technical direction of the IETF protocol parameter registries and 
maintaining the policies by which such technical directions are given. The IESG is responsible, as 
part of the document approval process associated with the IETF Stream RFCs [RFC8729], for 
"IANA Considerations" verification. For the other RFC streams, the approval bodies are 
responsible for verifying that the documents include "IANA Considerations" sections when 
needed, and that "IANA Considerations" sections conform to the current published guidelines. In 
the case that IANA considerations in non-IETF document streams lead to a dispute, the IAB 
makes the final decision. 


This document talks about "Registry Operator" (singular), and while there are stability and 
economy-of-scale advantages for one single Registry Operator, this document does not exclude 
having different Registry Operators for different protocol registries when justified by the 
circumstances. 
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4. Security Considerations 


This document does not propose any new protocols and does not introduce any new security 
considerations. 


5. IANA Considerations 


This document requires no direct IANA actions in terms of the creation or operation of a protocol 
parameter registry. However, this document does define the roles and responsibilities of various 
bodies who are responsible for, and associated with, the operation of protocol parameter 
registration functions for the IETF. 
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